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(54) Verfaliren, System und Gateway, die einen End-zu-End gesicherten Zugriff auf WAP-Dienste 
eriauben 



(57) Verfahren, mit welchem ein Mobilteilnehmer 
mit einem WAP-tauglichen Endgerat (1 ) auf einen WAP 
Oder WEB-Server (5) zugreifen kann, 
wobei das benannte Endgerat (1) eine Anfrage fur den 
benannten Server an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelle (2) zwi- 
schen dem benannten WAP-tauglichen Endgerat 
(1) und dem benannten Gateway (2) auf WTLS 
(Wireless Transport Layer Security) basiert, 
wobei der benannte Server (5) mit dem SSL und/ 



Oder TLS Sicherheitsprotokoll gesicliert ist, 
wobei die Konversion zwischen WTLS und SSL 
und/oder TLS in einem vom Verwalterdes benann- 
ten Servers (5) verwalteten gesiclierten Gebiet er- 
folgt, 

und wobei die Pakete, die vom benannten Endgerat 
(1) gesendet werden, vom benannten Gateway (3) 
zum benannten gesicherten Gebiet weitergeleitet 
werden, phne dass alle Pakete die wahrend einer 
Session ubertragen werden entschlusselt werden. 
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Beschreibung 

[0001] Die voriiegende Erfindung betrifft ein Verfahren. mit welchem ein Mobilteilnehmer mit einem WAP-tauglichen 
Endgerat auf einen WAP Oder WEB-Server zugreifen kann. 
5 [0002] WAP (Wireless Application Protocot)-Server, welche WAP basierte Dienste zur Verfugung stellen. sind an 
sich schon bekannt. Insbesondere sind auf WAP-basierte Dienste im Bereich von e-commerce und von finanzlellen 
Instituten erhaltlich. 

[0003] Solche Dienste verlangen eine gesicherte Paketubertragung zwischen den Endbenutzem und dem Server 
des Dienstanbieters. Die gewohnliche und vom WAP-Forum empfohlene Losung verwendetdie WTLS-Protokollschicht 

10 (Wireless Transport Layer Security); dieses Verfahren kann jedoch nur zum sichern der Paketubertragung zwischen 
den Endgeraten und einem (beispielsweise vom Mobilfunknetzbetreiber verwalteten) Gateway verwendet werden. In 
diesem Gateway wird eine Protokollubersetzung zum Sicherheitsprotokoll SSL 3.1 oder zum TLS 1 .0 durchgefuhrt. 
[0004] Das Prinzip einer mit diesem Verfahren gesicherten Datenubertragung ist schematisch auf der Figur 2 dar- 
gestellt. Mit dem Bezugszeichen 1 ist ein WAP taugliches Endgerat, beispielsweise ein WAP-taugllches GSM-Mobil- 

15 funktelefon (Global System for Mobile Communication) dargestellt, das sich Ober ein digitales Mobilfunknetz 2 mit 
einem vom Betreiber dieses Netzes venwalteten Gateway verblnden kann. Das Endgerat 1 enthalt ein Browser. Mit 5 
ist ein Server eines Dienstanbieters, beispielsweise eines Finanzinstituts oder eines Anbieters im e-commerce Bereich, 
dargestellt. Dieser Server kann auf eine Datenbank 51 zugreifen, in welcher WEB und/oder WAP-Seiten gespeichert 
sind. Die WEB oder WAP-Seiten konnen beispielsweise HTML-, WML-, JAVA-Script-, WML-Scrlpt-, usw.. Dokumente 

20 enthalten. 

[0005] Der Benutzer des Endgerats 1 , der auf eine WEB-oder WAP-Seite in der Datenbank 51 zugreifen kann, muss 
zu diesem Zweck eine mit WTLS-Diensten gesicherte Anfrage durch das Gateway 3 zum Sender 5 senden. DIese 
Anfrage wird im Gateway 3 durch alle Protokollschlchten eines Konvertierungsmoduls 30 entschlusselt, und dann in 
eine mit TLS oder SSL gesicherte Anfrage Qbersetzt, die Ober ein TCP/IP Netz 4 an den Server 5 gesendet wird. Im 
25 Server 5 kann ein anderes Ubersetzungsmodul vorgesehen werden, das diese Anfrage in ein elgenes Format konver- 
tlert. welches vom Datenbankverwaltungssystem 51 verstanden werden kann. Die Antwort vom Server 5, beispiels- 
weise der Inhalt einer WEB oder WAP-Seite, wird in der anderen Richtung Ober das Gateway 3, wo es umkonvertiert 
wird, zum Endgerat 1 geleitet. 

[0006] Dieses Verfahren eriaubt keine echte End-zu-End Verschlusselung; Daten und Pakete mflssen im Gateway 
30 3 entschlOsselt und wieder verschlOsselt werden, damit die ProtokollObersetzung durchgefuhrt wird. Fur viele Anwen- 
dungen ist eine solche SichertieltslOcke jedoch nicht akzeptierbar. 

[0007] Ein Ziel der vorliegenden Erfindung ist es, ein neues sichereres DatenObertragungsverfahren zwisq|ien einem 
Endgerat und einem WAP oder WEB-Server anzubieten. 

[0008] Ein anderes Ziel ist es, ein neues Verfahren anzubieten, mit welchem eine End-zu-End gesicherte Verbindung 
35 zwischen einem WAP-tauglichen Endgerat und einem WAP oder WEB-Server hergestellt werden kann. 

[0009] Ein weiteres Ziel ist es, ein neues Verfahren anzubieten, welches mit jedem WAP-tauglichen Endgerat das 

WTLS verwendet, eingesetzt werden kann, insbesondere mit Endgeraten. die eine Sen^erauthentlfizierung basierend 

auf einem RSA-SchlOssel, auf X.509v3 Zertlfikaten. auf RC5 oder auf anderen Sicherheitsprotokollen gemass WAP 

Oder WTLS, bzw. auf weiteren digitalen Zertlfikaten, verwenden. 
40 [0010] Gemass der vorliegenden Erfindung werden diese Ziele insbesondere durch die Merkmale der unabhangigen 

AnsprOche errelcht. Weitere vorteilhafte AusfOhrungsformen gehen ausserdem aus den abhangigen Anspruchen und 

der Beschreibung hervor. 

[0011] Insbesondere werden diese Ziele durch ein Verfahren erreicht, in welchem das benannte Endgerat eine An- 
frage fur den benannten Server an ein WAP-Gateway sendet, wobei die Sicherheit In der Luftschnittstelle zwischen 

45 dem benannten WAP-tauglichen Endgerat und dem benannten Gateway auf WTLS (Wireless Transport Layer Security) 
basiert, wobei der benannte Sender eine SSL und/oder TLS Protokoilschicht enthalt, wobei die Konversion zwischen 
WTLS und SSL und/oder TLS in einem vom Verwalter des benannten Servers verwalteten gesicherten Gebiet erfolgt, 
und wobei die Pakete, die vom benannten Endgerat gesendet werden, vorri benannten Gateway zum benannten ge- 
sicherten Gebiet weite rgele it et werden, ohne alle Pakete, die wahrend einer Session Obertragen werden. zu entschlOs- 

50 seln. 

[0012] Die Pakete werden durch eine sogenannten Tunnelschicht durch das Gateway Obertragen, ohne dass sle 
entschlOsselt werden. Dadurch bleibt der Inhalt selbst dem Betreiber des Gateways unbekannt. Die Pakete werden 
dann erst beim Server des Dienstanbieters In einem Proxy (sogenannten E2ES-Proxy) entschlOsselt und mit dem 
Zertlfikat einer vertrauten Drittinstanz verlflziert. 
55 [0013] Ausserdem werden diese Ziele durch ein Verfahren erreicht, mit welchem ein Mobilteilnehmer mit einem 
WAP-tauglichen Endgerat auf einen WAP oder WEB-Server zugreifen kann, wobei das benannte Endgerat eine An- 
frage fOr den benannten Server an ein WAP-Gateway sendet In welchem ein Browser im benannten Endgerat die 
Portnummer der beantragten WEB oder WAP-Seite extrahiert und In die zum benannten <3ateway gesendeten Pakete 
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kopiert, und in welchem die benannten Pakete Im benannten Gateway in Abhangigkeit von dleser Portnummer wei- 
tergeleitet werden: 

[0014] Ausserdem werden djese Ziele dadurch errecht, dass die Anfrage, die von einem Endgerat uber ein Gateway 
an einen WEB oder WAP-Server gesendet wird, mit WTLS End-zu-End geslchert wird. 
s [0015] Vorzugsweise kann im Gateway zwischen Sessionen, die konventionell behandelt werden sollen und Ses- 
sionen, die gemass der vorliegenden Erfindung weitergeleitet werden sollen, unterschieden werden. 
[0016] Im Folgenden werden anhand der beigefugten Zeichnung bevorzugte Ausfuhrungsbeispiele der Erfindung 
naher beschrieben: 

[0017] Die Figur 1 vergleicht die Protokollschichten in einem WAP-Protokoll-Stapel und Im Internet Protokoll-Stapel. 
10 [0018] Die oben beschriebene Figur 2 zeigt das Prinzip einer gesicherten Datenubertragung gemass dem normalen 
WAP-Protokoll. 

[0019] Die Figur 3 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer ersten Nferiante der Erfindung. 
[0020] Die Figur 4 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer zwelten N^riante der Erfin- 
dung. 

IS [0021] Die FigDr 5 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer dritten Variante der Erfindung. 
[0022] Die Figur 3 zeigt das Prinzip einer ersten N^rlante der Erfindung. Diese Figur zeigt ein in einem digltalen 
Mobilf unknetz 2 angemeldetes WAP-taugliches Endgerat 1 . beispielsweise ein WAP-taugliches GSM-Mobilf unktelefon 
Oder einen WAP-tauglichen tragbaren Rechner. Mit diesem Gerat kann ein Programm, beispielsweise ein WAP-Brow- 
ser. ausgefuhrt werden, das sich als Kunde mit einem WAP und/ oder WEB-Server 5 yerbinden kann und somit auf 

20 Daten in diesem Server zugreifen kann. 

[0023] Der WAP- oder WEB-Server 5 enthalt WML und/oder HTML-Selten, die beispielsweise von einem Dienstan- 
bieter (beispielsweise einem Finanzinstitut und/oder einem Anbieter im Bereich e-commerce) angeboten werden. Es 
wird oft von Dienstanbietern und Endbenutzem gewunscht, dass die Session die aufgebaut wird wenn ein Benutzer 
auf mehrere Seiten zugreift, gesichert wird. Insbesondere ist es oft notig, dass manche Daten, die in beiden RIchtungen 

2S zwischen dem Endgerat 1 und dem Server 5 ubertragen werden, End-zu-End gesichert werden und dass keine Dritt- 
partei, nicht einmal der Mobilfunknetzbetreiber, diese Daten entschlussein kann. Ausserdem wird eine gegenseitige 
Authentislerung des Dienstanbieters und des Mobilbenutzers benotigt. 

[0024] Der Benutzer des Endgerats kann eine gesicherte Seite erreichen, beispielsweise um eine Transaktion durch- 
zufuhren, Indem er beispielsweise auf den entsprechenden URL einer gesicherten oder nicht gesicherten Selte kllckt. 
30 Der vom Dienstanbleter definierte URL der Seite kann beispielsweise http://www.sp1 .com: 50443 lauten, wobei http:// 
www.splxom die URL-Adresse des Dienstanbleter und 50443 seine Portnummer ist. In Wap werden hingegen die 
fortlaufenden Portnummerbereiche 920x angewendet. 

[0025] Erfindungsgemass werden die URL in den WML und/oder HTML-Seiten der Dienstanbleter so verfasst, dass 
die gewunschte Sesslonsart (End-zu-End gesichert, Standard gesichert oder ungesichert) aus diesem URL, unter 
35 anderem aus der URL-Adresse und/oder aus der Portnummer, ermlttelt werden kann. 

[0026] Mit dem Bezugszeichen 3 ist ein ebenfalls dem Mobilf unknetz 2 angeschlossenes Gateway dargestellt. Das 
Gateway nimmt die Pakete vom Benutzer 1 entgegen und entschlusselt das oder die ersten Pakete in jeder Session, 
bis eine Anwendung 314 die Portnummer und die URL der gewunschten WEB oder WAP-Seite aus den Paketen 
extrahieren kann. 

40 [0027] Sobald diese Angaben gef unden worden sind, bestimmt die Anwendung 31 4 anhand den vom Verwalter des 
Gateways angegebenen Angaben, wie die Pakete bearbeltet werden sollen. Insbesondere bestimmt die Anwendung, 
Ob die Session zwischen dem Endgerat 1 und dem Server 5 End-zu-End gesichert werden soli. Dies Ist beispielsweise 
dann der Fall wenn sIch die Portnummer (beispielsweise 50443) in einer vom Administrator des Gateways aufgebauten 
LIste beflndet. 

45 [0028] Das Gateway 3 venwendet eine zusatzllche Protokollschlcht 310 (Tunnelschicht), die von der Anwendung 
314 gesteuert wird (Reil 315). Wenn die Session gesichert werden soil, wird die Tunnelschicht 310 so gesteuert, dass 
alle nachfolgenden Pakete der Session In transparenter Art durch das Gateway gefuhrt und an die Zieladresse des 
Sewers 5 weitergeleitet werden, ohne konvertlert und vor allem ohne entschlusselt zu werden. 
[0029] Die immer noch mit WTLS gesicherten Pakete der Session werden dann uber das Netz 4 weitergeleitet und 

so vom Server 5 im gesicherten Gebiet des Dienstanbieters entgegengenommen. Das Netz 4 kann beispielsweise aus 
dem Internet oder aus einer gemieteten Telefon-Linie bestehen. Der Server 5 umfasst ein Proxy 52 welches spater 
eriautert wird, ein konventlonelles Gateway 50, und eine Datenbank 51, in welcher ein WEB- und/ oder WAP-lnhalt 
abgelegt Ist. 

[0030] Das Proxy 52 Im Server 5 des Dienstanbieters wird so aufgebaut, dass es WTLS-geslcherte Sessionen ent- 
ss gegennehmen kann. Es umfasst vorzugsweise einen kompletten WAP-Protokoll-Stapel und kann somit durch vom 
Fachnnann leicht durchfOhrbare Anpassungen von standardisierter Software reallsiert werden. In diesem Proxy werden 
empfangene mit WTLS gesicherte WDP-Datagramme mit dem Zertiflkat einer vertrauten Drittinstanz gepruft, ent- 
schlusselt und in normale TCP-IP-Datagramme ubersetzt, wobei die HTTP-Session optional mit SSL gesichert werden 
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kann. Die TCP-IP konvertierten Pakete werden an den WAP- cxJer WEB-Sen^er 50 weitergeleitet, der eventuell sine 
andere Protokollkonvertierung durchf uhrt, damit die emptangene Abf rage vom Datenbanksystem 51 bearbeitet werden 
kann. 

[0031] Als Alternative konnen die Datagramrrte mit einem Session-Schlussel ver- und entschlusselt werden, dssen 
s Schlusset nnit Hilfe eines zertifizierten, offentlichen SchlQssel wahrend der Schlusselvereinbarungsphase generiert 
werden. 

[0032] Die Antwort vom WEB bzw. WAP-Server 50, zum Beispiel die gewunschte WEB- Oder WAP-Seite, wird vom 
Server 50 in die andere Richtung gesendet, im Proxy 52 ubersetzt und mit WTLS-Diensten gesichert und durch die 
"Tunnelschicht" 31 0 im Gateway 31 an das Endgerat 1 des Benutzers geleitet, wobei die gesamte Verbindung zwischen 

10 Server 5 und Endbenutzer 1 mit WTLS gesichert wird. 

[0033] Datagramme, die aufgrund des enthaltenen URL und/oder Portnummer keine End-zu-End gesicherte Daten- 
ubertragung verlangen, werden im Gateway 31 gemass der konventlonellen vom WAP-Forum empfohlenen Losung 
durch alle Schichten des Protokolls Im Gateway 2 entschlusselt, mit TLS/SSL wieder gesichert und an die in den 
Paketen angegebene URL-Adresse weitergeleitet. Beisplelsweise werden Sessionen mit der Portnummer 80 wie ge- 

15 wohnliche HTTP-Sessionen behandelt und weitergeleitet. 

[0034] Antworten vom Server 5 (beispielsweise die gewunschten WEB Oder WAP-Seiten) die keine WTLS-Sicherung 
zwischen Server und Gateway 3 verlangen, werden von der Proxy-Anwendung 524 durch eine Tunnelschicht 520 Im 
Proxy durchgefuhrt (Pfeil 315) und erst im Gateway 3 mit WTLS-Diensten gesichert. 

[0035] Diese Variante verlangt keine Anderungen vom Browser im Endgerat 11 und nur ein relativ einfaches Proxy 
20 53 beim Dienstanbieter 5, das WTLS-Sessionen entgegennehmen kann. Die Software-Implementation des Gateways 
3 kann sich jedoch als schwierig erweisen. 

[0036] Die zwelte Variante, die auf der Figur 4 dargestellt wird, eriaubt es, dieses Problem durch eine teicht durch- 
fuhrbare Anpassung der Anwendung (zum Beispiel des Browsers) im Endgerat 1 zu vermeiden. In dieser\feriante wind 
die URL-Adresse und die Portnummer der verlangten WEB Oder WAP-Seite vom Browser 10 In jedes Paket (WDP- 

25 Datagramm) der Session kopiert. Diese Pakete werden dann uber das Mobilfunknetz 2 an das Gateway 3 gesendet, 
wo die Portnummer und die URL analysiert werden, um zu ermittein wie die Pakete weiterbehandett werden sollen. 
[0037] Diese Variante hat den Vorteil, dass die Analyse und die Weiterbehandlung der Pakete In den unteren Schich- 
ten des Protokolls, unter anderem In der WDP und/oder WTLS-Schlcht, durchgefuhrt werden kann und dass sie somit 
nur minimale Anpassungen des Gateways 3 verlangt. 

30 [0038] Eine Tabelle 321 Im Gateway 3 Oder in einem nicht dargestellten Router vor dem Gateway gibt an, wie die 
Pakete je nach Portnummer und URL behandelt werden sollen und insbesondere welche Pakete transparent durch 
die Tunnelschicht 320 gehen sollen. Diese Tabelle kann vorzugsweise vom Administrator des Gateways 3 konfiguriert 
und geandert werden, ohne dass das Gateway neu gestartet werden muss, damit die Konflguration wahrend des 
Betriebes aktualisiert werden kann. Daten in der Tabelle konnen vorzugsweise nur vom Administrator geandert werden, 

35 Oder von Personen mit Administratorenrechten. 

[0039] Die Tabelle im Gateway 3 konnte beisplelsweise folgende Zellen enthalten: 







Eingegebene URL Adresse 


Neue Adresse (vom Gateway erteilt) 


Bemerkung 


40. 




Adresse 


Portnummer 


Adresse 


Portnummer 




45 


1 


138.10.20.30 


8040 


140.50.60.70 


12345 


Pakete mit dieser Adresse werden 
auf transparente Weise an die 
neue Adresse geleltet. Die 
Portnummer wird ersetzt 
(Mapping). 




2 


* * * * 


50443 


* * * * 


50443 


Stern-Joker eriauben eine 
Bedlngung fur alle Server mit der 
gleichen Portnummer zu setzen 


SO 


3 


138.10.20.40 


* 


138.10.20.40 


* 


Wie oben, jedoch ohne DNS- 
Lookup 




4 


www.sp1.com 


* 


www.sp1.com 


* 


Alle URL vom spl mussen durch 
die Tunnelschicht 


55 


5 


www.sp1.com 


80 


www.spl .com 


80 


Alle Verbindungen mit 
Portnummer 80 durch die 
Tunnelschicht 
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(fortgesetzt) 



5 





Eingegebene URL Adresse 


Neue Adresse (vom Gateway erteilt) 


Bemerkung 


Adresse 


Portnummer 


Adresse 


Portnummer 


6 


www.sp1.ch 


50443 


www.spl .ch 


50443 


sp1 verlangt, dass alle Sessionen 
mit der Portnummer 50443 durch 
die Tunnelschicht geleitet werden. 


7 


www.sp2.ch 


443 


www.sp2.ch 


443 


sp2 verlangt, dass alle Sessionen 
mit der Portnummer 443 dutch die 
Tunnelschicht geleitet werden. 
Damit wird kein SSL mit dem Port 
443 venwendet. SSL kann dann 
beispielsweise vom Proxy 
verwendet werden. 


8 













[0040] Der Administrator des Gateways 3 wird vorzugsweise den Dienstanbietern einen Bereich von URL-Adressen 
20 und/oder Portnummern zur Vertugung stellen. Dienstanbieter SP1 . SP2, usw. konnen dann eine Oder mehrere URL, 
Oder Portnummern, oder Kombinationen aus beiden, fur sich reservieren und den Administrator 3 anweisen, Pakete 
mit dieser URL und/oder Portnummer transparent weiterzuleiten. 

[0041] DleFigur5zeigtals Beispiel, wiedie Pakete, dievon verschiedenen Endbenutzem 1i bis l4gesendet werden, 
vom Gateway 3 in Abhangigkeit ihrer URL-Adresse und/oder Portnummer behandelt werden. 
25 [0042] Das dargestellte System umtasst in diesem Beispiel drel Server 5^ , 62 und 53 von drei verschiedenen Dienst- 
anbietem sp1, sp2 und isp3. Die vier folgenden Selten werden im ersten Server (bzw. 62) abgelegt: 

■ eIne ungesicherte WEB-Seite mit der Adresse www.spl .com:80 (bzw. www.sp2.com:80) 

30 m eine WE B-Seite mit der Adresse www.spl .com:443 (bzw. www.sp2.com:443), die nur mit SSL geslchert wird (keine 
End-zu-End Sicherheit) 

■ eine WEB-Seite mit der Adresse www.spl .com:50443 (bzw. www. sp2.com :50443), die mit WTLS gesichert wird 
(End-zu-End Sicherheit) 

3$ 

■ eine WAP-Seite mit der Adresse wap.spl .com: 50443 (bzw. wap.sp2.com: 50443), die mit WTLS gesichert wird 
(End-zu-End Sicherheit) 

[0043] Im Server 63 des dritten DIenstanbieters sp3 werden nur zwei Seiten abgelegt: 

40 

■ eine ungesicherte WEB-Seite mit der Adresse www.sp3.com:80 

■ eine WEB-Seite mit der Adresse www.sp3.com:443, die nur mit SSL gesichert wird (keine End-zu-End Sicherheit) 

45 [0044] Der erste Benutzer 1 ^ will auf die gesicherten Seiten www.spl .com:443 und www.spl xom:50443 des DIenst- 
anbieters SP1 im Server 5^ zugreifen, indem er GET(URL) Abfragen mit entsprechenden URL an das Gateway 3 
sendet. Das Gateway 3 erkennt anhand der Tabelle 321 und des im Datagramm enthaltenen URL und/oder der Port- 
nummer, welche Sicherheiten von diesen Seiten verlangt werden. Im ersten Fall (SSL Sicherheit) werden alle Data- 
gramme der Session Im Gateway 3 entschlusselt und eine Ubersetzung von WTLS zu SSL wird durchgefOhrt. Im 

so zweiten Fall (End-zu-End Sicherheit mit WTLS) werden alle Datagramme der Session transparent an den Server 5^ 
weitergeleitet, ohne dass sie entschlusselt werden. 

[0045] Der zwelte Benutzer 1 2 will auf die Seite www. sp2.com :50433 des DIenstanbieters sp2 Im Server 52 zugreifen, 
die eine End-zu-End Sicherheit verlangt. Datagramme mit djeser Adresse werden im Gateway 3 erkannt und transpa- 
rent durch die Tunnelschicht an den Server 62 geleitet. 
55 [0046] Der dritte Benutzer 1 3 will auf die Seite www.sp3.com:443 des DIenstanbieters sp2 im Server 63 zugreifen, 
die eine mit TLS/SSL gewahrleistete Sichertieit verlangt. WTLS-gesicherte Datagramme mit dieser Adresse werden 
im Gateway 3 erkannt, durch alle Schichten des Protokoll-Stapels ubersetzt, mit TLS/SSL gesichert und an den Server 
53 weitergeleitet. 
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[0047] Der vierte Benutzer I4 will auf die ungesicherte Seite www.sp3.com:80 des Dienstanbieters sp2 im Server 
62 zugreifen. WTLS-gesicherte Pakete mit dieser Adresse werden im Gateway 3 erkannt, durch alle Schichten des 
Protokoll-Stapels ubersetzt und an den Server 63 weitergeleitet, ohne sie durch das Netz 4 zu sichern. 
[0048] Diese Variante verlangt nur minimale Anderungen vom Gateway 3. Allerdings mussen die Browser-Anwen- 

s dungen in den Endgeraten 1 leicht angepasst werden, was sich bei vielen Anbietern als schwierig erweisen kann. 
[0049] Wir werden jetzt eine dritte Erfindungsvariante beschreiben, die diesen Nachteil vermeidet. 
[0050] In dieser Variants werden Sessionen die eine End-zu-End Sicherheit verlangen anhand der URL-Adresse 
und/cxier der Portnummer wie in der ersten oder zweiten Variante erkannt. Statt die Sessionen durch die Tunnelschlcht 
transparent weiterzuleiten, sendet das Gateway in diesenn Fall einen standardisierten Redirect-Befehl mit der in der 

TO Tabelle 321 angegebenen Adresse und Portnummer des Dienstanbieters und mit anderen Parameter fur die Identifi- 
zierung vom Gateway 5, wie Dial-In Nummer, an das Endgerat 1 . 

[0051] Die Weiterleitungsadresse (Adresse, Portnummer, Dial-In Nummer, usw..) im Redirect-Befehl wird vorzugs- 
wetse aus einem vom WAP Oder WEB-Sen^er 5 zuganglich gemachten Dokument extrahiert. Der Redirect-Befehl kann 
auch dieses oder ein anderes Dokument oder die Adresse eines solchen Dokuments enthalten, in welchem die Wei- 
15 terleitungsadresse enthalten ist. Im Dokument konnen vorzugsweise verschiedene Adressengebiete mit Strtngmuster, 
beispielsweise mit angegeben werden. 

[0052] Die Anwendung im Mobllgerat 1 , die diesen Redirect Befehl entgegennimmt, reagiert, indem sie jetzt die 
schon vorher an das Gateway 3 gesendeten Pakete wieder direkt an die im Redirect-Befehl angegebene Adresse des 
Dienstanbieters sendet 

20 [0053] Alle Pakete in der Session werden dann direkt zwischen dem Endgerat 1 und dem Server 5 ubertragen, bis 
der Endbenutzer einen anderen URL sendet, der vom Server 5 nicht bearbeitet werden kann (beispielsweise wenn 
sich die entsprechende gewunschte Seite nicht auf diesem Server befindet). In diesem Fall wird die Session vom 
Server 5 unterbrochen und die nachfolgenden Pakete werden wieder an das Gateway 3 gesendet. 
[0054] Falls keine End-zu-End Sicherheit benotigt wird, wird kein Redirect Befehl vom Gateway 3 gesendet. In die- 

25 sem Fall werden alle Pakete wahrend der gesicherten Sessbn durch das Gateway 3 gesendet. 

Patentanspruche 

30 1. Verfahren. mit welchem ein Mobilteilnehmer mit einem WAP-tauglichen Endgerat (1) auf einen WAP oder WEB- 
Server (5) zugreifen kann, 

wobei das benannte Endgerat (1 ) eine Anf rage fur den benannten Server an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelle (2) zwischen dem benannten WAP-tauglichen Endgerat (1) und 
35 dem benannten Gateway (3) auf WTLS (Wireless Transport Layer Security) basiert, 

wobei der benannte Server (5) mit dem SSL und/oder TLS Sicherheitsprotokoll gesichert ist, 

dadurch gekennzeichnet, dass die Konversion zwischen WTLS und SSL und/oder TLS in einem vom Ver- 
walter des benannten Senders (5) venwalteten gesicherten Gebiet erfolgt, 
40 und dass die Pakete. die vom benannten Endgerat (1) gesendet werden, vom benannten Gateway (3) zum 

benannten gesicherten Gebiet weitergeleitet werden, ohne alle Pakete die wahrend einer Session ubertragen 
werden zu entschlusseln. 

2. Verfahren gemass Anspruch 1 , dadurch gekennzeichnet, dass das benannte Gateway (3) die benannten Pakete 
45 zu einem Proxy (52) im benannten gesicherten Gebiet weiterleitet, wobei das benannte Proxy (52) mindestens 

eine Protokollschicht des WAP-Protokolls verwendet. 

3. Verfahren gemass einem der Anspruche 1 oder 2, in welchem die benannten Pakete in Abhangigkeit vom URI 
und/oder vom Domainname der angefragte Seite im benannten Gateway (3) weitergeleitet werden. 

so 

4. Verfahren gemass einem der vorhergehenden Anspruche, in welchem die benannten Pakete abhangig von der 
Portnummer im benannten Gateway (3) weitergeleitet werden. 

5. Verfahren gemass dem vorhergehenden Anspruch, In welchem die benannten Pakete abhangig von verschiede- 
55 nen Portnummem an verschiedene gesicherte Gebiete weitergeleitet werden. 

6. Verfahren gemass einem der Anspruche 4 oder 5, in welchem die benannte Portnummer aus der URI und/oder 
URL der angefragten Seite in einer Anwendungsschicht des benannten Gateways (3) extrahiert werden. 
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7. Verfahren gemass Anspruch 6, in welchem die benannte Portnummer wahrend einer Session nur aus einer be- 
grenzten Anzahl von Paketen extrahiert wird, 

und in welchem das Weiterleiten von mindestens einem folgenden Paket von dieser benannten extrahierten 
Portnummer abhangig ist. 

5 

8. Verfahren gemass Anspruch 7, in welchem ein Proxyserver (52) im benannten gesicherten Geblet die URI und/ 
Oder die Portnummer der empfangenen Pakete extrahiert, und in welchem der benannte Proxyserver (52) dem 
benannten Gateway (3) einen Befehl zurOcksendet, wenn er ein Paket mit einer anderen URI und/oder mit einer 
anderen Portnummer empfangt. 

10 

9. Verfahren gemass einem der Anspruche 4 oder 5, in welchem die benannte Portnummer aus dem benannten URI 
und/oder URL der angefragten Webseite im benannten Endgerat (1 ) extrahiert wird. 

10. Verfahren gemass Anspruch 9, in welchem die benannte Portnummer von einem Browser aus dem URI und/oder 
IS URL der angefragten Webseite extrahiert wird. 

1 1 . Verfahren gemass einem der Anspruche 8 Oder 9, in welchem der Browser im benannten Endgerat (1 ) die benannte 
Portnummer in den benannten Paketen erst dann kopiert, wenn eine End-zu-End gesicherte Verbindung beantragt 
ist. 

20 

12. Verfahren gemass einem der Anspruche 3 bis 11, in welchem die benannten Pakete im benannten Gateway (3) 
an ein gesichertes Geblet weitergeteitet werden wenn sich die benannte Portnummer in einem vorbestimmten 
Bereich befindet. 

25 13. Verfahren gemass Anspruch 1 , dadurch gekennzeichnet, dass wenn eine End-zu-End gesicherte Verbindung be- 
antragt ist, das benannte Gateway (3) einen Redirect-Befehl zum benannten Endgerat (1) sendet. 

14, Verfahren gemass dem vorhergehenden Anspruch, in welchem der benannte Redirect Befehl zeitlich begrenzt ist. 

30 15. Verfahren gemass Anspruch 1 3, in welchem ein Proxy Server (52) im benannten gesicherten Geblet die URI und/ 
Oder die Portnummer der empfangenen Pakete extrahiert, und einen Redirect Befehl zuruck zum benannten End- 
gerat (1 ) sendet, sobald die Session zum benannten Gateway (3) weitergelertet werden soil. 

16. Verfahren gemass Anspruch 13, in welchem den benannten Redirect-Befehl eine Welterleltungsadresse enthalt, 
35 die aus einem vom benannten WAP oder WEB-Server (5) zuganglich gemachten Dokument extrahiert wird. 

17. Verfahren gemass dem Anspruch 13, in welchem den benannten Redirect-Befehl ein Dokument enthalt, in wel- 
chem die Welterleltungsadresse enthatten ist. 

40 18. Verfahren, mit welchem ein Moblltellnehmer mit einem WAP-taugllchen Endgerat (1) auf einen WAP oder WEB- 
Server (5) zugrelfen kann, 

wobei das benannte Endgerat (1) eine Anfrage fur den benannten Server (5) an ein WAP-Gateway (3) sendet. 
dadurch gekennzeichnet, dass ein Browser Im benannten Endgerat (1) die Portnummer der beantragten WEB 
Oder WAP-Seite extrahiert und In zum benannten Gateway (3) gesendete Paketen kopiert, 
45 und dass die benannten Pakete im benannten Gateway (3) in Abhangigkeit von dieser Portnummer weitergelertet 

werden. 

19. Gateway (3), das mit WTLS-gesrcherte Datagramme von WAP-tauglichen Endgeraten entgegennehmen und in 
SSL-gesicherte-Abfragen ubersetzen kann, 

50 dadurch gekennzeichnet, dass es Datagramme erkennen kann, die in transparenter Welse weitergelertet 

werden sollen und dass es diese Datagramme ohne sie zu entschlussein weiterleiten kann. 

20. Gateway gemass dem vorhergehenden Anspruch. in welchem die benannten Pakete in Abhangigkeit vom URI 
und/oder vom Domainname der angefragten Seite weitergeleitet werden. 

55 

21. Gateway gemass einem der Anspruche 19 oder 20, In welchem die benannten Pakete in Abhangigkert von der 
Portnummer im benannten Gateway (3) weitergelertet werden. 
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22. Gateway gemass dem vorhergehenden Anspruch, in welchem die benannten Pakete abhangig von verschiedenen 
Portnummem an verschiedene gesicherte Gebiete weitergeleitet warden. . 

23. Gateway gemass einem der Anspruche 21 Oder 22, in welchem die benannte Portnummer aus dem URI und/oder 
s URL der angefragten Seite in einer Anwendungsschicht des benannten Gateways (3) extrahiert warden. 

24. Gateway gemass Anspruch 21 , in welchem die benannte Portnummer wahrend einer Session nur aus einer be- 
grenzten Anzahl von Paketen extrahiert werden, 

und in welchem das Weiterleiten von mindestens einem folgenden Paket von dieser benannten extrahierten 
10 Portnummer abhangig ist. 
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